第二次參加it鐵人賽，去年以跟工作有關的Java和AWS為主題，開啟兩個30天，今年一樣從工作碰過的技術出發，決定開啟PostgreSQL 30天旅程。
想要開啟這段旅程的原因，主要是因為平常在碰資料庫，大多只使用CRUD的SQL語法，比較沒有更多探索PostgreSQL的功能和設計，所以決定開啟這個系列(但這個系列還是會從CRUD當起點開始XD)。
除了讓自己更熟悉關聯式資料庫系統，期待以後在面對不同資料的使用情境時，可以更好的思考，如何選擇適合的資料庫(ex:選關聯式資料庫好，還是選NoSQL好)！
這個系列主要的規劃是
也歡迎大家來我的medium看這一個系列的分享：https://medium.com/judys-database-sharing
敲碗，我想更多了解 pg 如何儲存schema less 的 JSON和JSONB，這兩個又有什麼差別與優勢。
JSON/JSONB如果能用 GIN, BTRee, hash, trigram 這些索引類型的話，是不是代表, 其實 pg 根本也不需要嚴格定義出欄位與約束了，直接都用 json/jsonb 就好 XD
純粹是看到這句 除了讓自己更熟悉關聯式資料庫系統，期待以後在面對不同資料的使用情境時，可以更好的思考，如何選擇適合的資料庫(ex:選關聯式資料庫好，還是選NoSQL好)！ 才想到的敲碗。
剛剛查了一下官網，JSONB可以用GIN, BTRee 和 hash，不過使用BTRee和hash的意義似乎不大，因為是拿整個document去做比對查詢，無法拿其中一個欄位去做查詢，GIN可以更好的支援JSON的查詢，因為GIN有支援@>, @? and @@ 這幾個operator，可以指定JSON欄位做查詢。
https://www.postgresql.org/docs/current/datatype-json.html#JSON-INDEXING
"pg 根本也不需要嚴格定義出欄位與約束了，直接都用 json/jsonb 就好" => 這個我覺得很值得探討，來寫兩篇文章，一篇介紹JSON和JSONB，一篇做實驗研究一下，用jsonb搭配GIN這個索引的效能會比較好，還是用有特定型別的欄位搭配Btree或GIN的效能會比較好，或許也可以跟Elastic Search之類的做比較看看，如果pg的全文檢索比Elastic Search之類的好，那是不是可以可以讓pg扛下一切，不用再多維護一種技術XDD
iThome鐵人賽
看影片追技術